Okay, so welcome back to Introduction to Software Engineering.

And today we want to continue to talk about the requirements engineering that we started

in the last session already.

And I can only emphasize requirements engineering is really, really important.

And it's, you know, as many of the techniques that we learn here, we want to understand

and want to learn how to effectively collaborate in software projects.

And this is now, we're essentially going in this lecture through the software lifecycle,

right?

So in the beginning, we had to think about how to work on software.

These were the software processes we discussed.

And now we are thinking about how we actually want to start a project.

So now we think about the very beginning and that's the requirement specification.

So this is before any line of code is written.

We're starting to think about the requirements and we have seen a couple of different categorizations

of requirements, first of all, into in particular functional and non-functional requirements.

That's kind of a very important differentiation.

Function is essentially something the system does and non-functional is a property of the system.

You could argue about that and we went through a couple of examples, whether they are functional

and non-functional.

Then, of course, there's also other classification schemes in particular for the non-functional

requirements and we've seen that quite a few of them stem from the product.

So they are concerning usability, security, and dependability and efficiency requirements.

And you can further also go into a direction that is an organizational requirement.

So there we had environmental requirements in which work environment I'm in.

So are there certain standards that have to be kept and that can also introduce new requirements.

Then also operational requirements that depends on the operation and then developmental requirements.

And last we also had external factors.

So we skim through this very quickly.

The external factors can be given by the regulatory bodies, for example, if you're working in

medical engineering, then for example, device regulations apply and you will have to comply

with these device regulations because otherwise you won't be able to sell your product in the end.

Of course, also ethical requirements are very important point and ethical requirements have

been not regarded very well in many software projects and you can see if you skim through

media there is quite a few in particular in the AI direction.

There's all these biases that people are not modeling correctly and things like that actually

go into the ethical requirements.

And then there can also be a legislative requirements.

It really then depends whether it's legislative.

So there can be laws that your software have to fulfill, but there can also be regulatory

requirements, which is then something like a regulatory body that is checking on your

product and you have to pass a certain test before you can sell it.

So these would be examples.

Legislative requirements is something that you observe, for example, in accounting and

things like that.

If you do a tax return software, then of course you have to follow the tax regulation laws

and they give requirements towards your software.

Alright, we have three examples here.

The Medicare system shall be available to all clinics during normal working hours.

So this is something that is really connected to the organization.

So this is, it depends on the clinic, but it's not a function.